1. Field
The invention relates to modifying an application and more specifically to modifying one or more modules in an application.
2. Description of the Related Art
The OSGi Alliance is a standards organization that has defined a dynamic module framework for Java™. (Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.)
The unit of modularity defined by OSGi is an OSGi “bundle” which is a jar archive containing OSGi metadata as additional headers in the jar manifest. The concept of an “application” comprised of multiple bundles is not standardized yet in OSGi, but technologies such as SpringSource dm Server and Apache Aries have defined an application as a collection of OSGi bundles (code modules; a code module may comprise a single piece of code or a plurality of files).
An OSGi bundle has a version, exports (makes available for use by other bundles, packages, etc.) Java packages at a version and imports (declares a dependency upon) Java packages at a fixed version or within a range of versions. Packages correspond to directories within a bundle. Those directories include files.
An application descriptor indicates the bundles that make up a particular application and the required version or version range for each bundle. The required OSGi bundles can be resolved from a bundle repository using the application descriptor (note that multiple repositories may be used).
As shown in FIG. 1a, application descriptor 10 indicates that there are 3 bundles A, B and C in application X. Each bundle is required at a specified version or within a particular version range. Thus, bundle A should be within the range 1.0 to 2.1 (exclusive); bundle B should be in the range 1.1 to 1.4 (exclusive); and bundle C should be at version 2.5. Note, in OSGi parlance, a range is typically specified [x, y). This means from x up to but not including y. The ending) indicates “not inclusive”, whilst the ending] indicates “inclusive”. Further, [and] are both inclusive and (and) are both exclusive.
A bundle repository 20 comprises bundles at various versions. In this example, A is present at versions 1.0, 1.1 and 1.5; B is present at 1.1; and C is present at version 2.5. Typically an application will be resolved to include the latest acceptable version of each bundle (as defined by the application descriptor) which is present in the bundle repository. Therefore, as shown in FIG. 1b, application X will comprise bundle A at version 1.5; bundle B at version 1.1; and bundle C at version 2.5.
Having resolved application X, there may subsequently be a reason to upgrade one of the bundles in application X. For example, a problem may be discovered with bundle B at version 1.1 such that it is desirable to upgrade to a more recent version.
The bundle repository may have had many bundles added into the repository in the period subsequent to when application X was first resolved. This is shown in FIG. 1c. The bundle repository contains the following new bundles which were not present in the repository shown in FIG. 1a: A at version 1.7; A at version 1.8; A at version 2.0; and B at versions 1.2 and version 1.3.
When application X is re-resolved, current OSGi resolvers such as that included in the Apache Felix OSGi Bundle Repository's OBR Service API aggressively resolve all bundles to the latest acceptable version (as specified in the application descriptor). This means that the entire dependency network is resolved to the latest consistent set of versions (e.g. the set that meets all the dependency requirements). This is not necessarily desirable since each application will have been tested and quality assured using specific bundles. Even though a bundle has specified a range that it supports, it may not have actually been tested for all versions within the range; rather there may be a long term plan to eventually test the bundle with all versions within the supported range.